feat(comment-commands): auto suggest reviewers on pr open/update via git blame#5651
Conversation
…t-review-no-args feat: assign reviewer on /request-review with no arguments
…t-review-no-args test(comment-commands): add blame-parser tests
Signed-off-by: oplaws <juucceey@gmail.com>
Co-authored-by: Matthew B. <mgball@uci.edu> Signed-off-by: Julie Cao <116243642+juliethecao@users.noreply.github.com>
…git blame Add a suggest-reviewers CI job that runs on pull_request (opened, synchronize, reopened). It blame-scans changed files, splits candidates into committers (requestable) and non-committer contributors (cc-only), then posts or updates a single suggestion comment per PR. Explicit @mentions are still required; the suggestion comment provides the candidates to choose from.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5651 +/- ##
============================================
- Coverage 52.96% 52.91% -0.06%
- Complexity 2523 2628 +105
============================================
Files 1075 1090 +15
Lines 41743 42208 +465
Branches 4513 4531 +18
============================================
+ Hits 22109 22333 +224
- Misses 18330 18569 +239
- Partials 1304 1306 +2
*This pull request uses carry forward flags. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
✅ No material benchmark regressions detected🟢 7 better · 🔴 0 worse · ⚪ 8 noise (<±5%) · 0 without baseline
Baseline detailsLatest main
Raw CSVconfig_idx,batch_size,schema_width,string_len,num_batches,total_ms,total_tuples,total_bytes,tuples_per_sec,mb_per_sec,lat_p50_us,lat_p95_us,lat_p99_us
0,10,10,64,20,451.04,200,128000,443,0.271,21142.67,32328.44,32328.44
1,100,10,64,20,2097.51,2000,1280000,954,0.582,102805.09,135526.12,135526.12
2,1000,10,64,20,17825.67,20000,12800000,1122,0.685,891169.73,913913.99,913913.99 |
|
I see on your fork run This is not ideal right? for a new file, there is no blame history. will it go to blame the parent folder or related file? Could you test on three cases:
To see the recommendations of each? |
For all three test PRs, I used
Let me know if the modify case should use a more representative file (e.g. something with richer blame history across more contributors). On the delete case: I currently skip deleted files, but since the file existed at the base commit, |
Ma77Ball
left a comment
There was a problem hiding this comment.
I left some quick changes below. After those are addressed, the design LGTM!
…t renaming Co-authored-by: Matthew B. <mgball@uci.edu> Signed-off-by: Julie Cao <116243642+juliethecao@users.noreply.github.com>
…naming logic Co-authored-by: Matthew B. <mgball@uci.edu> Signed-off-by: Julie Cao <116243642+juliethecao@users.noreply.github.com>
|
@juliethecao let's make sure the suggestion won't actually tag a person. for example in juliethecao#11 if you @Ma77Ball he will receive a github notification. if you Sorry Matthew for using your account as an example |
What changes were proposed in this PR?
This PR adds an automatic reviewer suggestion CI job to
.github/workflows/comment-commands.yml. When a PR is opened or updated (pull_request: opened, synchronize, reopened), the CI automatically runsgit blame -pat the base commit on each changed file to identify who most recently touched that code. Candidates are split into two groups:The CI posts a comment in this format:
Suggested reviewers (based on git blame of changed files):Committers — can be formally requested: @ alice, @ bobNon-committer contributors — cc to notify: @ carolUse /request-review @ alice to request a review, or cc @ carol to notify them.On every subsequent push, the job finds the existing suggestion comment (via a hidden HTML marker ) and edits it in place, keeping the PR timeline clean. The CI never sends a review request on its own as the author must explicitly use /request-review @ user.
Files with status added are skipped before git blame is attempted since they did not exist at the base commit.
Any related issues, documentation, discussions?
Closes #5611
How was this PR tested?
Unit tests: 83 tests across 9 suites were written locally (https://github.com/juliethecao/texera/tree/cc-test) to cover the core JavaScript logic extracted from the workflow:
git blame -poutput parsing, candidate ranking, comment body generation, find-or-update marker logic, author/bot exclusion, @ mention parsing, file status filtering, candidate accumulation, and MARKER integrity. Tests were not checked in as the logic lives inside a GitHub Actions script rather than a standalone module.Manual CI test: A test PR was opened on a personal fork (juliethecao#9) against the feature branch as the base. The suggest-reviewers job triggered on open, ran git blame on the changed files, and posted the suggestion comment. Closing and reopening the PR confirmed the comment was updated in place rather than duplicated.
Was this PR authored or co-authored using generative AI tooling?
Co-authored with Claude Sonnet 4.6 in compliance with ASF guidelines